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Services are autonomous, self-describing, technology-neutral software units that can be described, 
published, discovered, and composed into software applications at runtime. Designing software 
services and composing services in order to form applications or composite services requires ab- 
stractions beyond those found in typical object-oriented programming languages. This paper ex- 
plores service-oriented abstractions such as service adaptation, discovery, and querying in an object- 
oriented setting. We develop a formal model of adaptive object-oriented groups which offer services 
to their environment. These groups fit directly into the object-oriented paradigm in the sense that 
they can be dynamically created, they have an identity, and they can receive method calls. In contrast 
to objects, groups are not used for structuring code. A group exports its services through interfaces 
and relies on objects to implement these services. Objects may join or leave different groups. Groups 
may dynamically export new interfaces, they support service discovery, and they can be queried at 
runtime for the interfaces they support. We define an operational semantics and a static type system 
for this model of adaptive object groups, and show that well-typed programs do not cause method- 
not-understood errors at runtime. 

1 Introduction 

Good software design often advocates a loose coupling between the classes and objects making up a 
system. Various mechanisms have been proposed to achieve this, including programming to interfaces, 
object groups, and service-oriented abstractions such as service discovery. By programming to interfaces, 
client code can be written independently of the specific classes that implement a service, using interfaces 
describing the services as types in the program. Object groups loosely organize a collection of objects 
that are capable of addressing a range of requests, reflecting the structure of real-world groups and social 
organizations in which membership is dynamic [18]; e.g., subscription groups, work groups, service 
groups, access groups, location groups, etc. Service discovery allows suitable entities (such as objects) 
that provide a desired service to be found dynamically, generally based on a query on some kind of 
interface. An advantage of designing software using these mechanisms is that the software is more 
readily adaptable. In particular, the structure of the groups can change and new services can be provided 
to replace old ones. The queries to discover objects are based on interface rather than class, so the 
software implementing the interface can be dynamically replaced by newer, better versions, offering 
improved services. 

This paper explores service-oriented abstractions such as service adaptation, discovery, and querying 
in an object-oriented setting. Designing software services and composing services in order to form 
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applications or composite services require abstractions beyond those found in typical object-oriented 
programming languages. To this end, we develop a formal model of adaptive object-oriented groups that 
also play the role of service providers for their environment. These groups can be dynamically created, 
they have identity, and they can respond to methods calls, analogously with objects in the object-oriented 
paradigm. In contrast to objects, groups are not used for executing code. A group exports its services 
through interfaces and relies on objects to implement these services. From the perspective of client code, 
groups may be used as if they were objects by programming to interfaces. However, groups support 
service-oriented abstractions not supported by objects. In particular, groups may dynamically export 
new interfaces, they support service discovery, and they can be queried at runtime for the interfaces they 
support. Groups are loosely assembled from objects: objects may dynamically join or leave different 
groups. In this paper we develop an operational semantics and a static type system for this adaptive 
group model based on interfaces, interface queries, groups, and service discovery. The type system 
ensures that well-typed programs do not cause method-not-understood errors at runtime. 

The paper is organized as follows. Section |2] presents the language syntax and a small example. 
A type and effect system for the language is proposed in Section [3] and an operational semantics in 
Sectional Section [5] defines a runtime type system and shows that the execution of well-typed programs 
is type-safe. Section[6]discusses related work and Section|7] concludes the paper. 

2 A Kernel Language for Adaptive Object Groups 

We study an integration of service-oriented abstractions in an object-oriented setting by defining a kernel 
object-oriented language with a Java-like syntax, in the style of Featherweight Java [14]. In contrast to 
Featherweight Java, types are different from classes in this language: interfaces describe services as sets 
of method signatures and classes generate objects which implement interfaces. By programming to inter- 
faces, the client need not know how a service is implemented. For this reason, the language has a notion 
of group which dynamically connects interfaces to implementations. Groups are first-class citizens; they 
have identities and may be passed around. An object may dynamically join a group and thereby add new 
services to this group, extending the group's supported interfaces. Objects may be part of several groups. 
Both objects and groups may join and leave groups, thereby migrating their services between groups. 
The kernel language considers concurrent objects which interact by synchronous method calls. Con- 
current activities are triggered by instantiating classes with run methods (similar to overriding the run 
method of Java's Thread class). This simple concurrency model is relevant for service-oriented systems. 

2.1 The Syntax 

The syntax of the kernel language is given in Figure Q] A type T in the kernel language is either a 
basic type, an interface describing a service, or a group of interfaces. A program P consists of a list 
IF of interface declarations, a list CL of class declarations, and a main block {T x;s}. The main block 
introduces a scope with local variables x typed by the types T, and a sequence s of program statements. 
We conventionally denote by x a list or set of the syntactic construct x (in this case, a program variable), 
and furthermore we write T x for the list of typed variable declarations T\ x\\ . . . ;T n x n where we assume 
that the length of the two lists T and x is the same. The types T are the basic type Bool of Boolean 
expressions, the empty interface Any, the names / of the declared interfaces, and group types Group(7) 
which state that a group supports the set 7 of interfaces. The use of types is further detailed in Section |3l 
including the subtyping relation and the type system. 
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Interface declarations IF associate a name I with a set of method signatures. These method signa- 
tures may be inherited from other interfaces 7 or they may be declared directly as Sg. A method signature 
Sg associates a return type T with a name m and method parameters x with declared types T. 

Class declarations CL have the form class C(T x) implements 7 {T\ x~i;{T2 x~2~;s};M} and asso- 
ciates a class name C to the services declared in the interfaces 7. In C, these services are realized using 
methods to manipulate the fields xj of types T\. The constructor block {T2 xj',s} initializes the fields, 
based on the actual values of the formal class parameters x of types T. Remark that the constructor block 
is executed asynchronously. Consequently, it can be used to trigger concurrent activities stalling in a new 
instance of a class. The methods M have a signature Sg and a method body {T x; s; return x; } which 
introduces a scope with local variables x of types T where the sequence of statements s is executed, after 
which the expression e is returned to the client. 

The expressions e of the kernel language consist of Java-like expressions for reading program vari- 
ables x, method calls x.m(x) where the actual method parameters are given by x, and object creation 
new C(x) where the actual constructor parameters are given by x. Method calls are synchronous and in 
contrast to Java all method calls are synchronized; i.e., a caller blocks until a method returns and a callee 
will only accept a remote call when it is idle. For simplicity, the kernel language supports self-calls but 
not re-entrance (which could be addressed using thread identities as in Featherweight Java CHI)- In addi- 
tion, we consider two expressions which are related to service-oriented software: newgroup dynamically 
creates a new, empty group which does not offer any services to the environment. Service discovery may 
be localized to a named group y: the expression acquire I in y except x finds some group g or object o 
such that g or o offers a service better than I (in the sense of subtyping) and such that g or o is not in the 
set x. If the in y clause is omitted, then the service provider g or o may be found anywhere in the system. 

The statements s of the kernel language include standard statements such as skip, assignments x = e, 
sequential composition s\;s2, conditionals, and while-loops. To simplify the kernel language, we keep 
a flat representation of expressions; i.e., expressions must be assigned to program variables before they 
can be used in other statements. Service interfaces 7 are dynamically exported through a group y by the 
expression x joins y as 7, which states that object or group x is used to implement the interfaces 7 in the 
group y. Consequently, y will support the interfaces 7 after x has joined the group. Objects and groups x 
may try to withdraw service interfaces 7 from a group y by the expression x leaves y as 7 {s\ } else {^2}- 
Withdrawing interfaces from a group can lead to runtime exceptions which need to be handled either by 
the client or by the service provider. In our approach, the exception is handled on the server side; i.e., 
withdrawing interfaces 7 from y only succeeds if y continues to offer all the interfaces of 7, exported 
by other objects or groups. Thus, removals may not affect the type of y. If the removal is success- 
ful then branch s\ is taken, otherwise S2 is taken. In addition, the language includes the statement 
x subtypeOf I y {si} else {^2} which is used to query a known group x about its supported interfaces. 
The statement works like a conditional and branches the execution depending on whether the query suc- 
ceeds or not. If x offers an interface better than I, the expanded knowledge of the group x becomes 
available through the variable y in the scope of the statements s\. Ifx does not offer an interface as good 
as 7, the branch S2 is taken. Remark the introduction of a new name for the group inside the scope, which 
ensures that the knowledge of the extended type is local. (By syntactic sugar, the variable y need not 
appear in the surface syntax). 

2.2 Example 

We illustrate the dynamic organization of objects in groups by an example of software which provides 
text editing support (inspired by 1221 "). This software provides two interfaces: Speiichecker allows 
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Definitions. 
P ::= IFCL {T x; s} 
T ::= Bool | Any | / | Group{7) 
IF ::= interface / extends 7{Sg} 
CL ::= class C(Tx) implements 7 {7 x; {T x;s};M} 
Sg ::= Tm(\Tx}) 
M ::= Sg {T x; s; return x; } 

e ::= x\x.m(x) |new C(x) newgroup | acquire / [in x] except x 
s ::= skip|x = e|s;s|if x {s} else{.v} | while x{s} 
x joins x as I\x leaves ias7 {s} else {.v} 
x subtypeOf / x {.«} else {.?} 

Figure 1: Syntax of the kernel language. The type names T include interfaces names / and Bool. Square 
brackets [] denotes optional elements. 

the spell-checking of a piece of text and Dictionary provides functionality to update the underlying 
dictionary with new words, alternate spellings, etc. Apart from an underlying shared catalog of words, 
these two interfaces need not share state and may be implemented by different classes. Let us assume 
that the overall system contains several versions of Dictionary, some of which may have an integrated 
speiichecker. Consider a class implementing a text editor factory, which manages groups implement- 
ing these two interfaces. The factory has two methods: makeEditor dynamically assembles such soft- 
ware into a text editor group and repiaceDictionary allows the Dictionary to be dynamically replaced 
in such a group. These methods may be defined as follows: 

Group{SpellChecker , Dictionary) makeEditor () { 
Group(0) editor; SpellChecker s; Dictionary d; 
editor = newgroup; 

d = acquire Dictionary except emptyset; 
d subtypeOf SpellChecker ds { 

ds joins editor as Dictionary, SpellChecker; 
} else { 

d joins editor as Dictionary; 

s = new SpellChecker () ; 

s joins editor as SpellChecker; 

} 

return editor; 

} 

void repiaceDictionary (Group(SpellChecker, Dictionary) editor, Dictionary nd) { 
Dictionary od; 

nd joins editor as Dictionary; 

od = acquire Dictionary in editor except nd; 

od leaves editor as Dictionary {skip;} else {skip;}; 

return; 

} 

The method makeEditor acquires a top-level service d which exports the interface Dictionary (since 
there is no in-clause in the acquire-expression). If d also supports the SpellChecker interface, we let 
d join the newly created group editor as both Dictionary and SpellChecker. Otherwise d joins the 
editor group only as Dictionary. In this case a new SpellChecker object is created and added to 
the group as SpellChecker. Remark that we assumed the presence of several Dictionary services in 
the overall system, otherwise the initial acquire-expression may not succeed and execution could be 



Syntactic Categories. 
C : Class name 
/ : Interface name 
T:Type name 
m: Method name 
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(T-Call) 



(T-NEW) 
rhx: ptypes(C) C<I 



(T-Var) 

r\-x-.r(x) 



T\-x:T' 



rhx:T 



match(m,T .T') retType{T' .m) — T 



T h new C(x) : I 



T h x.m(x) : T 



(T-GROUP) 
T h newgroup : Group{0) 



(T-ACQUIRE) 
T h >•: Group (S) 



(T-SUB) 



T X T 



rhc:r 



r h acquire / in y except x : I 



Figure 2: The type system for expressions. 



blocked at this point. The kernel language could be extended by a more robust version of acquire which 
uses branching (similar to subtypeof); in fact, inside a group g, robustness may be obtained by first 
checking for the existence of an interface I in g using subtypeof and then binding to the object or group 
implementing I in g using acquire. 

The method repiaceDictionary will replace the Dictionary service in a text editor group. First 
we add the new Dictionary service nd to the editor group and then we fetch the old service od in the 
group by means of an acquire, where the except-clause is used to avoid binding to the new service nd. 
Finally the old service od is removed as Dictionary in the group by a leave statement. The example 
illustrates group management by joining and leaving mechanisms as well as service discovery. 



The language distinguishes behavior from implementations by using an interface as a type which de- 
scribes a service. Classes are not types in source programs. A class can implement a number of service 
interfaces, so its instances can export these services to clients. A program variable typed by an interface 
can refer to an instance of any class which implements that interface. A group typed by Group(7) ex- 
ports the services described by the set 7 of interfaces to clients, so a program variable of type / may refer 
to the group if / € 7. We denote by Any the "empty" interface, which extends no interface and declares 
no method signatures. A service described by an interface may consist of only some of the methods 
defined in a class which implements the interface, so interfaces lead to a natural notion of hiding for 
classes. In addition to the source program types used by the programmer, class names are used to type 
the self-reference this; i.e., a class name is used as an interface type which exports all the methods 
defined in the class. 

Subtyping. The subtype relation -< is defined as the transitive closure of the extends-relation on inter- 
faces: if / extends /' and /' -< J or f = J, then / -< /. It is implicitly assumed that all interfaces extends 
Any, so we let / -< Any for all /. A group type Group(S') is a subtype of / if there is some J £ S such that 
J ~<I, and Group(>S) -< Group(5 ,/ ) if for all J £ S' there is some I £ S such that / -< J. We extend the 
source language subtype relation by letting a class be a subtype of all its implemented interfaces. The 
reflexive closure of -< is denoted ^. 

Typing contexts. A typing context F binds variable names to types. If F is a typing context, x a 
variable, and T a type, we denote by dom(r) the set of names which are bound to types in F (the domain 
of F) and by F(x) the type bound to x in F. Define the update F[x ^ T] of a typing context F by 
F[x i-> T\ (x) = T and F[x >->■ T] (y) = F(y) if y ^ x. By extension, if x and T denote lists x\,...,x n and 



3 A Type and Effects System 
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(T-Skip) 
r h skip : ok 



(T-ASSIGN) 
The: r(x) 
r h x = e : ok 



(T-RETURN) 
rKv:ok(A) ToAhjciT 
T hi; return x :T 



(T-COMPOSITION) 

rhs:ok(Ai) roA! h s' : ok{A 2 ) 
T\-s;s' : ok{Ai oA 2 > 



T(x) = Bool 



(T-CONDITIONAL) 
rhs 1 :ok{A 1 ) rh.s 2 :ok(A 2 ) 



rh if Jt{ii}else{i 2 } : ok(Ai nA 2 ) 



(T- While) 
r(*) = Bool Fhs: ok{A) 
rh while x{s} : ok(A) 



(T-JOIN) 

localiy) T{y) = Group(S) Y{x) -< I 
Th.v joins y as 7: ok(y h-> Group{5U/)) 



(T-LEAVE) 
r(jc) -< 7 T(v) = Group(S) 
rh.s I :ok(A I ) rh.v 2 :ok(A 2 > 



rh.t leaves y as / {s t } else {.v 2 } : ok(A,nA 2 ) 



(T-lNSPECT) 
r(jc) = Group(S) y g dom(T) 
r[y M-Group(SU{/})] hs, : ok(A,) Th.v 2 : ok(A 2 ) 
rhi subtypeOf / y {s t } else {s 2 } : ok(Ai nA 2 ) 

(T-Class) 
T[this i-> C,xi >-> 25] h M : ok 
C<1 r[this^C,x 2 "^7 2 ".?r^77,xJn-73] hi :ok(A> 



(T-METHOD) 

r' = r[x^T,7 ^ Y 7 ] 

T' h.v; return e: T"(A) 



rh T" m (T x){T' a:';*; return x\ : ok 



(T-PROGRAM) 
r[x^T] hi:ok(A> 
VCL6CL-ThCL:ok 



Th class C(T\ xT) implements / {T 2 W,{ T i X3',s};M} : ok rh IF CL {T x;s\ : ok 

Figure 3: The type and effect system for statements, methods, classes, and programs. 



T\ , . . . , T n , we may write r[x h-^ T] for the typing context F[xi >->• Ti] . . . [x n \-t T n ] and r[3cT t-> Ti,X2 •->■ 7a] 
for r[jq i — >• 7j~| [jc2 " — >■ 7^1 - F° r typing contexts Ti and T2, we define Ti o Yj such that Ti o T2 (x) = T2 (x) if 
x € dom(r2) and Ti o T2(x) = F\ (x) ifx$ dom(r2). 

For typing contexts Ti and T2, we define the intersection Y\ nT2 by Ti nT2(x) = T if T is the best 
type such that ri(x) = T\, Tz{x) = T2, and T\ <T and T2 < T. In particular, we have Yy nr2(x) = 
Group(5i PlS2) if Ti(x) = Group(5i) and ^(jc) = Group^). 



The Type and Effect System. Programs in the kernel language are analyzed using a type and effect 
system (e.g., (2l[T9j|24l). The inference rules for expressions are given in Figure [2] and for statements, 
methods, classes, and programs in Figure [3] 

Expressions are typed by the rules in Figure |2 Let T be a typing context. A typing judgment 
T h e : T states that the expression e has the type T if the variables in e are typed according to T. By T- 
VAR, variables must be typed in T. Method calls to a method m on a variable x are typed to T if x has the 
(interface) type T such that the types T of the actual parameters x give a match for m in T with parameter 
types T and the declared return type of m in T' is T . In T-New, new C has type / if the types of the 
actual parameters to the class constructor can be typed to the declared types of the formal parameters of 
the class, by means of the auxiliary function ptypes, and the class implements I, expressed by C -< I. We 
omit the definitions of the auxiliary functions match and retType here, these are straightforward lookup 
functions on the program's interface table which perform the matching and retrieve the return type of a 
method in a class, respectively. Similarly, ptypes retrieves the types of the formal parameters to a class 
in the program's class table. By T-GROUP, a new group has the empty group type (with no exported 
interfaces). By T- ACQUIRE, service discovery has the obvious type, if successful. The premise of the 
rule is omitted if the statement has no in-clause. Rule T-Sub captures subtyping in the type system. 
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Statements are typed by the rules in Figure [3] Let T and A be typing contexts. A typing judgment 
rhs: ok (A) expresses that the statement s is well-typed if the variables in s are typed according to 
r and that the typing context for further analysis should be modified according to the effect A. Empty 
effects are omitted in the presentation of the rules. The typing of statements skip and x = e are standard. 
These judgments have no effects. The statement return x has a return type and is typed in the effect 
of typing the statements of the method body. The use of effects can be seen in rule T-COMPOSITION, 
where the second statement is type checked in the typing context modified by the effect of analyzing the 
first statement, and the effects are accumulated in the conclusion of the rule. Rules T-CONDITIONAL 
and T-While propagate effects from the subexpressions; in the case of T-CONDITIONAL the resulting 
effect is approximated by taking the intersection of the effects of the branches. By T-JOIN, when an 
object joins a group y and contributes interfaces 7 to y, the effect is that the type of y is extended with the 
interfaces 7. Note the requirement locally), which expresses that y must be a local variable in the scope 
of the method being analyzed. (We omit the definition, which is again a lookup in the class table of the 
program). Without this restriction, a field could dynamically extend its type, resulting in an unsound 
system; e.g., an assignment f =e in a statically well-typed method could become unsound if the type of 
f were extended. However extending the type t of a local variable which copies the value of f to a type 
t' and assigning the result back to a field f ' is allowed, as f ' would need to be of the extended type t' 
and f would remain of type t as required by the other method. (For comparison, the needed restriction 
to local variables is handled differently in the query statement subtypeOf , which introduces a fresh local 
variable.) Rule T-Leave shows that leaving a group has no effect on the typing context, and the effects 
of the two branches are treated as for the conditional. Rule T-lNSPECT shows how the typing context is 
extended with a new variable y which extends the type of the group x for the scope of the branch s\. The 
overall effect is again the intersection of the effects of the two branches. 

Programs, classes, and methods are typed in the standard way. Methods do not have effects, which 
reflects that effects are constrained to local variables inside methods. Likewise, classes and programs do 
not have effects. (For simplicity, the standard type checking of interface declarations is omitted in the 
presentation.) The body of a class constructor and the main method of a program may have the same 
effects as the body of a method. 

4 Operational Semantics 

The runtime syntax is given in Figure @] A runtime configuration cn is either the empty configuration 
£ or it consists of objects obj and groups grp. Groups grp have an identity g and contain a set export 
of interfaces / associated with the objects o implementing them. Objects obj have an identity o, a state 
a, and a stack p of processes proc. When an object has processes to execute, it executes the process at 
the top of its stack. The stack grows with self-calls and shrinks at method returns. The empty stack is 
denoted idle. A state a maps program variables x to their types T and values v. A process proc can be 
error or it has a local state a and a sequence s; return x; of statements to be executed. The expression 
wait(o,m) encodes a lock, expressing that the object is waiting for the return value of method m in 
another object o (or on an auxiliary self-call). Values v include object and group names, and Booleans. 

The operational semantics is given by rules in the style of SOS EH . reflecting small-step semantics. 
Each rule describes one step in the execution of an object. Concurrent execution is given by standard SOS 
context and concurrency rules (not shown here), and we assume associative and commutative matching 
over configurations (as in rewriting logic Q). Thus objects execute concurrently, with the following 
exceptions: The rule for synchronous remote call (CallI) refers to both the caller and callee objects 
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Syntactic Categories, 
g: Group name 
o: Object name 



Definitions. 



cn 



£ | grp | obj | cn cn 
g(export) 

{o '. /} | export U export 
o(f7, p) 

r'rf/e I proc I proc; p 
m{o~ |.vr} I error 

iHt (r,v) nod 

wait(o,m) I ... 



export 



obj 



P 



proc 



a 



e 



sr ::= s | s;return x; 



v 



o\g\ true I false 



Figure 4: The runtime syntax, extending the language syntax for expressions e and statements s. 

and therefore the two objects must synchronize and the caller will be blocked by the wait statement. 
Furthermore rules involving an object and a group will lock the group in question, thereby disallowing 
concurrent execution of other objects involving the same group. This is crucial in the JOIN and Leave 1 
rules for joins and leaves, which may actually modify the group. 

We define the lookup of a program variable x in a state a by a(x) = (T,v), with the projections 
cj t (x) = T and <J V (x) = v. Thus, for a state a, o T gives the associated mapping of program variables to 
their types and o v the mapping of program variables to their values. The Skip rule is standard and states 
that a skip has no effect. The effect of assignment is divided into two rules, AssiGNl for local variables, 
updating I, and ASSIGN2 for fields, updating a. In the rule New-Group, a globally unique group 
identifier is found by fresh(g). Then an empty group with this identifier is added to the configuration. 
The two rules CONDl and COND2 handle the two cases of the conditional statement. 

Method calls are handled by CallI for calls to other objects, CALL2 for self calls, and Call3 for 
calls to groups. When a call is made to another object in CallI, the called object must be in an idle 
state. The caller blocks until the generated wait statement can be executed. In the wait statement, the 
callee and method name are recorded, which allows the runtime type system to infer the proper type 
of the return value from method m in the proper class. Let bind(m,C,v) denote the process resulting 
from the activation of method m in C, in which / maps the parameters of m to their declared types and 
values v, and the local variables to their declared types and default values. The callee gets the process 
bind(m,C , (a o l) v (y)), where C is the class of the callee, pushed onto its process stack p. With self 
calls in CALL2, the process stack cannot be idle, but a wait statement replaces the call statement and an 
instance of the called method is pushed to the stack. In Call3, a call to a group is reduced to a call to a 
group or an object inside the callee which exports an appropriate interface to the group. By appropriate 
we mean that the called method is supported by the interface (formally, m G mtd(I)). RETURN 1 handles 
returns from remote calls. Here the blocking wait statement is replaced by the returned value. Returns 
from self calls are handled in a similar way by the RETURN2 rule. (Remark that the generalization 
to concurrent objects with asynchronous calls and futures is straightforward as in (6l[T5l whereas the 
extension to multi-threaded programs would require re-entrant lock as in lfl4lD . 

The new statement is handled by the New-Obiect rule, where fresh(o',C) asserts that o' is a new 
name in the global configuration such that classOf(o') = C. An object with this name is created. The 
mapping atts(C, v) maps the declared fields of class C to their declared types and default values, this to 
C, and the class parameters to declared types and actual values. The process init(C) corresponds to the 
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init-block of C, which instantiates local variables to their declared types and default values. The process 
of the new object is the initial process of its class. Note that an init-block is executed independently from 
the creator, so it may trigger active behavior, for instance, the init-block can call a run method. 

The rule JOIN extends the knowledge of a group with the new interfaces from the object's perspective 
and correspondingly extends the exports set from the group's perspective. Service discovery is handled 
by the ACQUIRE rule. The acquire expression is replaced by a value v, which is an object or group 
identifier satisfying the in and except clauses. If the in clause is omitted from the expression, then the 
premise (a o l) v (y) = g is omitted from the rule. Note that this rule will block if no matching object or 
group exists. This could be solved by either returning null (by means of a global check) or by adding 
an else branch similar to those in Query 1 and Query2. Within the kernel language, the existence of 
a matching object or group inside a group can be checked using the query mechanisms. 

The leaves statement is handled by the rules Leave 1 for a successful leave and Leave2 for an 
unsuccessful one. A group or object x may leave a group successfully if the group provides the same 
interface support without x. To determine this, we use the function intf (export) which returns a set con- 
taining the interfaces of all the pairs in export, removing redundant information. An entry is redundant if 
a subtype of the entry is present in the set. The type of the group does not change by a leaves statement 
and hence the object does not need to update information about the group. The branches s\ or S2 are 
chosen depending on the success. The rules Query 1 and Query2 handle the branching statement that 
checks if a group exports a given interface. If the test succeeds then a fresh variable y is introduced and 
is only visible in s\. The type of this variable is the union of what the current object already knew about 
the group and the new information /. If the test fails the S2 branch is chosen by Query2. 

The initial state. For a program P = IF CL {T x;s}, we define the initial state to be o(e,main{x H> 
(T ,default(T))\s;}) where o is such that fresh(o, Main). 

5 Type Safety 

This section extends the type system of Section[3]to runtime configurations and shows that the execution 
of well-typed programs remains well-typed. 

5.1 Well-Typed Configurations 

The extension of the type system to runtime configurations is given in Figure [6l The typing context 
r stores the types of all constant values (object and group identities) at runtime. By RTT-CONFIG, a 
configuration is well-typed if all objects and groups are well-typed. By RTT-GROUP, a group is well- 
typed if all the objects which export interfaces through the group implement these interfaces (checked 
by RTT-EXPS and RTT-Exp). By RTT-Object, an object is well-typed if its class is its type in T and 
its state and stack are well-typed in the context of the types of the fields. Substitutions (the state of fields 
and local variables) are checked by RTT-SUBS and RTT-SUB. The stack is well-typed by RTT-Stack 
if all its processes are well-typed by RTT-PROC; i.e., the state of local variables and the method body sr 
are well-typed. Observe that due to the query-mechanism of the language, the types of program variables 
in two processes which stem from activations of the same method, may differ at runtime. For this reason, 
the typing context used for typing runtime configurations cannot rely on the statically declared types of 
program variables. This explains why RTT-PROC extends T with the locally stored typing information l T 
to type check l v and sr. The effects of the static type system are not needed here, as they are reflected by 
how the operational semantics updates this local type information. For consistency in the presentation, 
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(Skip) 
o(a,m{l | skip;.sr};p) 
— > o(a,m{l | sr};p) 



(ASSIGNl) 

x G dom(l) 
f(x) = T (aol) v (y) = v 
o(a,m{l | x = y;sr};p) — > 
o(a,m{l[x n> (r,v)] | sr};p) 



(ASSIGN2) 

x £ dom(l) 
a T (x) = T (aol) v (y) = v 

o(a,m{l | x = y;.sr};p) — > 
o(a[x 1-4- (T,v)],m{/ | sr};p) 



(New-Group) 

fresh(g) 



o(a,m{l | x = newgroup; sr};p) 
-+o(a,m{l\x = g;sr};p) g(H>) 



(CONDI) 

(aol) V (x) 

o(a,m{l\if x {si} else {s2};sr};p) 
— > (o(a,m{/|«i;«r};p) 



(COND2) 

^(aol) V (x) 

o(a,m{l\if x {.vi} else {s2};sr};p) 
— > o(a,m{Z|.V2;.sr};p) 



(While) 
o(a,m{l | while a: {si};,sr};p) 
— ► o(a,m{l | if x {ii ; while a: {.vi}} 
else {skip} ;sr};p) 



(CALLl) 

(a o /) v (y) = o' classOf(o') = C 
pr = bind(m,C, (aol) v (y)) 
o(a,m{l \ x = y.m(y);sr};p) o'(a',idle) — > 
o(a,m{l x = wait(o', m);«r};p) o'(a',pr) 



(CALL2) 
(a o /) 17 (y) = o classOf{o) = C 

pr = bind(m,C, (aol) v (y)) 
o(a,m{l | a: = y.m(y);sr};p) — > 
o(a,pr;m{l x = wa±t(o,m);sr};p) 



(CALL3) 

(«°0 V (>•) = § 

v : / € exports m G mtd(I) 
o(a,m{l \ x = y.m(y);sr};p) g(exports) 
-> o(a,m{/ | x = v.m(y);sr};p) g(exports) 



(RETURNl) (RETURN2) (NEW-OBIECT) 

(aol) v (x)=v p = idle (aol) v (x)=v fresh(o' ,C) pr = init(C) 



o(a,m{l | return x;};p) o(a,m{l | return x;}; a' = atts(C, (aol) v (x)) 



d (a', m'{l' | >■ = wait(o, m);sr};p') m'{l' y = wait(o, m);sr};p) o(a,m{l\x = new C(x);sr};p) 

— ► o(a,p) o'(a',m'{l' \ y = v;sr};p') — > o(a,m'{l' \ y = v;.sr};p) — > o(a,m{7|x = o';*r};p) o'(a' ,pr) 



(Join) 

(ao/) v W=v Z(y) = <Group(S),g) 
7 = Group{SU7) exports' = U/gj{ v : 1} U exports 
o(a,m{l\x joins y as 7;.sr};p) g(exports) 
-> o(a,m{7[y (7\s)]|w};p) g(exports') 



(Acquire) 

(aoZ) l '(3)) =g (v: J) e exports J x / v ^ (ao/) v (x) 
o(a,m{l | x = acquire / in y except x;sr};p) g(exports) 
-> o(a,m{l | x = v;sr};p) g(exports) 



(Leave 1) 
(«o/) v (y)=« (ao/) v W=v 
exports' = exports \ \J Ie j{v : 1} intf (exports) = intf (exports') 
o(a,m{l\x leaves y as 7 {.vi} else {.S2};.w};p) g(exports) 
— > o(a,m{l\si ;sr};p) g(exports') 



(LEAVE2) 

(aoO v (y) = « (ao/) v W=v 
exports' = exports \ \J Ie j{v : 1} intf (exports) ^ intf (exports') 
o(a,m{l\x leaves y as 7 {si} else {.S2};f};p) g(exports) 
o(a,m{l\s2',sr};p) g(exports) 



( Query 1) (Query2) 
y^dom(aol) aol(x) = (Group o' :J E exports J -< I (aol) v (x) = g Gxovcp(intf (exports)) / / 



o(a,m{l\x subtypeOf / y {.vi} else {s2};f };p) o(a,m{l\x subtypeOf / y {si} else {s2};-«"};p) 

g(exports) g(exports) 
■ o(a,m{/[y M> (Group{5U {/},#))] |si ',sr};p) g(exports) o(a,m{l\s2',sr};p) g(exports) 



Figure 5: The operational semantics. 
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(RTT-EMPTY) 
r h £ : ok 

(RTT-CONFIG) 
r\- cn : ok r h cn' : ok 
F h cn cn' : ok 



(RTT-IDLE) 
T h idle : ok 

(RTT-GROUP) 

r h exports : T(g) 
r h g(exports) : ok 



(RTT-WAIT) 
r h wait (o.m) : retType(classOf(o) ,m) 



(RTT-EXP) 
leS r(o) -< / 
r h o : I : Group<5> 



(RTT-DEF) 

T h default(T) : T 

(RTT-SUB) (RTT-SUBS) 

r h v : T(jc) r h a : ok T h d : ok 



rhjKv: ok 



r h a o a' : ok 



(RTT-OBJECT) 
r' = roa r T'ha^iok 
classOf{o) = T(o) r' h p : ok 
Tho{a,p) :ok 



(RTT-EXPS) 
r h exports : Group (S) 
r h exports' : Group{5) 



(RTT-PROC) 

r' = To/ r T(this)=C 
r' \- l v : ok r' h sr : retType(C,m) 



r h exports U exports' : Group(S') T h m{l\sr; } : ok 

Figure 6: The runtime type system. 



(RTT-STACK) 
r h proc : ok 
T h p : ok 
F h proc\p : ok 



the typing of fields is represented in the same way, although these types are not altered by the execution. 
The rules from the static type checking are reused as appropriate. 

5.2 Subject Reduction 

The type system guarantees that the type of fields in an object never changes at runtime (in particular, re- 
call the restriction local{y) in rule T-JOIN). This allows us to establish in Lemma[T]from the static typing 
of methods in well-typed programs that method binding, if successful, results in a well-typed process at 
runtime. To show that the error process cannot occur in the execution of well-typed programs, it suf- 
fices to show that substitutions are always well-typed. Lemma|2] shows that this is the case for the initial 
configuration and Lemma [3] shows that one execution step preserves runtime well-typedness. Together, 
these lemmas establish a subject reduction theorem for the language, expressing that well-typedness is 
preserved during the execution of well-typed programs and in particular that method binding always 
succeeds. Here, A denotes the reflexive and transitive closure of the reduction relation — K 

Lemma 1 Assume that a well-typed program has a class C which defines a method m with formal para- 
meters x of type T and return type T. Let o be an object such that classOf{o) = C and T h o(a,p) : ok. 
IfT h v : T, then Toa T \- bind(m,C,v) : T. 

Lemma 2 Let P be a program such that T h P : ok and let cn be the initial state of P. Then T h cn : ok. 

Lemma 3 IfT h cn : ok and cn —¥ cn' then there is a T' such that T' h cn' : ok and F C r'. 

Theorem 1 (Subject reduction) Let F h P and let cn be the initial runtime state of P. If cn cn' then 
there is a F' such that F' h cn' : ok and F C F'. 



6 Related Work 

Object orientation is well-suited for designing small units which encapsulate state with behavior, but 
does not directly address the organization of more complex software units with rich interfaces. Two 
approaches to building flexible and adaptive complex software systems involve, independently, object 
groups and service discovery. Our work unifies these two approaches in a formal, type-safe setting. 

The most common use of object groups is to provide replicated services in order to offer better fault 
tolerance. Communication to elements of a group is via multicast. This idea originated in the Amoeba 
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operating system |fl6l . The component model Jgroup/ARM GUI adopts this idea to provide autonomous 
replication management using distributed object groups. In this setting, members of a group main- 
tain a replicated state for reasons of consistency. The ProActive active object programming model 
supports abstractions for object groups, which enable group communication — via method call — and var- 
ious means for synchronizing on the results of such method calls, such as wait-for-one and wait-for-all. 
ProActive is formalized in Caromel and Henrio's Theory of Distributed Objects [4]. These notions of 
group differ from ours in two respects. Firstly, in these approaches communication with groups is via 
multicast, whereas in our approach each message will be delivered to exactly one object, and secondly, 
in the formal theory, groups are fixed upon creation. Furthermore, there is no notion of service discovery 
associated with groups. 

Object groups have been investigated as a modularization unit for objects which is complementary to 
components. Groups meet the needs of organizing and describing the statics and dynamics of networks 
of collaborating objects [18 ]; groups can have many threads of control, they support roles (or interfaces), 
and objects may dynamically join and leave groups. Lea |[T8l presents a number of common usages for 
groups and discusses their design possibilities, inspired from CORBA. Groups have been used to provide 
an abstraction akin to a notion of component. For example, in Oracle Siebel 8.2 [8], groups are used as 
units of deployment, units of monitoring, and units of control when deploying and operating components 
on Siebel servers. Our approach abstracts from most of these details, though groups are treated as first 
class entities in our calculus. 

Another early work on groups is ActorSpaces [1], which combine Actors with Linda's pattern match- 
ing facility, allowing both one-to-one communication, multicast, and querying. Unlike our approach, 
groups in ActorSpaces are intensional: all actors with the same interface belong to the same group. Fur- 
thermore ActorSpaces support broadcast communication to a group, which has not been considered in 
this paper as it would differentiate communication with an object and with a group. Compared to our 
paper, these works do not give a formalization of group behavior or discuss typing. 

Object groups have further been used for coordination purposes. For example, CoLaS [9] is a coor- 
dination model based on groups in which objects may join and leave groups. CoLaS goes beyond the 
model in our paper by allowing very intrusive coordination of message delivery based on a coordinator 
state. In our model, the groups don't have any state beyond the state of their objects. Similar to our 
model, objects enroll to group roles (similar to interfaces). However, unlike our model objects may leave 
a group at any time, and the coordinator may access the state of participants. The model is implemented 
in Smalltalk and neither formalization nor typing is discussed [9]. Concurrent object groups have also 
been proposed to define collaborating objects with a single thread of control in programming and model- 
ing languages H15U23II . Concurrent object groups do not have identity and function as runtime restrictions 
on concurrency rather than as a linguistic concept. 

Microsoft's Component Object Model (COM) supports querying a component to check whether it 
supports a specific interface, similar to the query-mechanism considered in this paper. A component in 
COM may also have several interfaces, which are independent of each other. In contrast to the model 
presented in our paper, COM is not object-oriented and the interfaces of a component are stable (i.e., they 
do not change). COM has proven difficult to formalize; Pucella develops \ C0M [22], a typed A -calculus 
which addresses COM components in terms of their interfaces, and discusses extensions to the calculus 
to capture subtyping, querying for interfaces, and aggregation. 

A wide range of service discovery mechanisms exist lTT3l . The programming language Ambi- 
entTalk ifTOTl has built-in service discovery mechanisms, integrated in an object-oriented language with 
asynchronous method calls and futures. In contrast to our work, AmbientTalk is an untyped language, 
and lacks any compile time guarantees. Various works formalise the notion of service discovery ifTTl . 
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but they often do so in a formalism quite far removed from the standard setting in which a program using 
service discovery would be written, namely, an object-oriented setting. For example, Fiadeiro et al.'s lITO 
model of service discovery and binding takes an algebraic and graph-theoretic approach, but it lacks the 
concise operational notion of service discovery formalized in our model. No type system is presented 
either. 

Some systems work has been done that combines groups and service discovery mechanisms, such as 
group-based service discovery mechanisms in mobile ad-hoc networks (5][32]]. In a sense our approach 
provides language-based abstractions for a mechanism like this, except that ours also is tied to interface 
types to ensure type soundness and includes a notion of exclusion to filter matched services. 

Our earlier work (6] enabled objects to advertise and retract interfaces to which other objects could 
bind, using a primitive service discovery mechanism. A group mechanism was also investigated as a way 
of providing structure to the services. In that work services were equated with single objects, whereas in 
the present work a group service is a collection of objects exporting their interfaces. In particular, this 
means that the type of a group can change over time as it comes to support more functionality. 

The key differences with most of the discussed works is that the model in this paper remains within 
the object-oriented approach, multiple groups may implement an advertised service in different ways, and 
our formalism offers a transparent group-based service discovery mechanism with primitive exclusion 
policies. Furthermore, our notion of groups has an implicit and dynamically changing interface. 

7 Conclusion 

The paper has proposed a formal model for adaptive service-oriented systems, based on a notion of 
object-oriented groups. We develop a kernel object-oriented language in which groups are first-class 
citizens in the sense that they may play the role of objects; i.e., a reference typed by an interface may 
refer to an object or to a group. A main advantage is that one may collect several objects into a group, 
thereby obtaining a rich interface reflecting a complex service, which can be seen as a single object from 
the outside. Although objects in our language are restricted to executing one method activation at the 
time, a group may serve many clients at the same time due to inner concurrency. 

In contrast to objects, groups may dynamically add support for an increasing number of interfaces. 
The formation of groups is dynamic; join and leave primitives in the kernel language allow the migration 
of services provided by objects and inner groups as well as software upgrade, provided that interfaces 
are not removed from a group. An object or group may be part of several groups at the same time. This 
gives a very flexible notion of group. 

Adaptive object groups are combined with service discovery by means of acquire and subtypeOf con- 
structs in the kernel language, which allow a programmer to discover services in an open and unknown 
environment or in a known group, and to query interface support of a given object or group. These 
mechanisms are formalized in a general object-oriented setting, based on experiences from a prototype 
Maude [7 ] implementation of the group and service discovery primitives. The presented model provides 
expressive mechanisms for adaptive services in the setting of object-oriented programming with modest 
conceptual additions. We have developed an operational semantics and type and effects system for the 
kernel language, and show the soundness of the approach by a proof of type-safety. 

The combination of features proposed in this paper suggests that our notion of a group can be made 
into a powerful programming concept. The work presented in this paper may be further extended in 
a number of directions. The overall goal of our work is to study an integration of service-oriented 
and object-oriented paradigms based on a formal foundation. In future work, we plan to extend the 
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proposed kernel language to multi-thread concurrency and study in more detail how different usages of 
object groups such as replication, resource, and access groups (see, e.g., f\M ) may be captured using 
the proposed primitives. It is also interesting to study the integration into the kernel language of more 
service-oriented concepts such as for example error propagation and handling, as well as high-level group 
management operations such as group aggregation. 
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